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Abstract 


This document specifies a new extension for use in Mobile IPv4. This 
extension can be added by the Home Agent and the Foreign Agent to 
Registration Reply messages. This extension carries a text string 
that is intended for the user of the Mobile Node. 
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Les 


Introduction 


This document specifies a new skippable extension that can be added 
by the Foreign Agent and Home Agent in any registration message 
targeted for the Mobile Node. Such a message may be either a 
Registration Reply or Registration Revocation (i.e., co-located 
Care-of Address mode). For the Registration Reply message, this 
extension can be added regardless of whether the registration has 
succeeded or failed. 


The content of the text string in this extension and its usage by the 
Mobile Node is implementation specific. The text string in this 
extension is intended for the user of the Mobile Node. For example, 
this message can be displayed on the Mobile Node’s user interface, 
logged, or handled in any other implementation dependent way, 
depending on the form of the Mobile Node. 


Typical contents of the text string will indicate a registration 
failure reason, or give a welcome message on successful registration. 
This is important, as the failure reason code gives very limited 
information for interpretation by the user of the Mobile Node. For 
example, a string like "registration failed : Prepaid Quota for the 
user is exhausted" can give a human readable description of the 
result of Mobile IP registration. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Mobile IPv4 Message String Extension Format 


The Message String Extension conforms to the Short Extension format 
specified for Mobile IPv4 [RFC3344]. The Message String Extension is 
a skippable extension. 


0 1 2 3 
012 34 5-6 7 89012 3 4567 8 9 0-1 2 3 45 678 9-0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Sub-Type | Text 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 


145: An 8-bit identifier of the type mobility option. 
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4. 


Length: 


An 8-bit unsigned integer. Length of the extension, in bytes, 
excluding the extension Type and the extension Length fields. 
This field MUST be set to 1 plus the total length of the Text 
field. 


Sub-Type: 

1: Extension comes from the Home Agent 

2: Extension comes from the Foreign Agent 
Text: 


The Text field is one or more octets, and its contents are 
implementation dependent. It is intended to be human readable, 
and MUST NOT affect the operation of the protocol. The message 
MUST be in UTF-8 encoded IS0-10646 [RFC3629] characters. The 
number of octets in the encoded representation of the message is 
always exactly the value of the Length field minus one. (The 
number of unicode characters represented by this octet sequence 
may be smaller than the number of octets.) 


Operation and Use of the Message String Extension 


The Message String Extension is only valid for use within Mobile IPv4 
Registration Reply and Registration Revocation messages. The Message 
String Extension is a skippable extension. Either the Home Agent or 
Foreign Agent or both can add the Message String Extension to 
registration messages. The usage of Text field of the Message String 
Extension is implementation dependent. For example, the message can 
be displayed on the Mobile Node’s user interface, logged, or handled 
in an implementation dependent way, depending on the form of the 
Mobile Node. The Mobile Node may throttle how often the user is 
notified of the message. 


As an example, the Home Agent may reject the first Registration 
Request because the prepaid quota for the user is reached and may 
attach a Message String Extension with the text "Prepaid quota 
reached. Please contact www.paymore.example.com to update balance". 
The Mobile Node could display this on the user interface. Asa 
response, the user of the Mobile Node may take the required action to 
update the prepaid account and retry the registration process. The 
Home Agent may accept this Registration Request and attach a Message 
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String Extension with the text "Welcome to 
www.serviceprovider.example.com". The Mobile Node could display this 
on the user interface, thus confirming a successful creation of 
binding on Home Agent. 


In the case that the message is not originated by the Home Agent 
itself, but for instance, is received from a RADIUS server [RFC2865], 
it could be received in some other encoding than UTF-8. If so, the 
Home Agent MUST convert the message to UTF-8 encoded ISO-10646 
[RFC3629] characters. 


5. Security Considerations 


The Message String Extension can be added by the Home Agent or 
Foreign Agent or both. The protection of the extension is based on 
the ordering method specified for message authentication in RFC 3344 
[RFC3344] and emphasized below. 


If the extension is added by the Home Agent (extension with subtype 
1) to a Registration Reply or Registration Revocation message, it 
MUST appear before Mobile-Home Authentication Extension [RFC3344]. 


If the extension is added by the Foreign Agent (extension with 
subtype 2) to a Registration Reply message, it MUST appear after 
Mobile-Home Authentication Extension [RFC3344] whenever present. 

Also the extension MUST appear before the Mobile-Foreign 
Authentication Extension whenever present. However, since security 
association between the Mobile Node and Foreign Agent is optional, it 
is possible that the extension is not authenticated in this case. 


There is no confidentiality provided by the extension; the message is 
transferred unencrypted, and if sensitive information is sent for 
display purposes, it may need to be protected by other means. 


6. IANA Considerations 


This specification reserves number 145 for the Message String 
Extension in Section 3 from the space of numbers for skippable 
mobility extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] 
at http://www.iana.org/assignments/mobileip-numbers. 


This specification also creates a new subtype space for the type 


number of this extension. The subtype values 1 and 2 are defined in 
this specification. The subtype value 1 is reserved for use by the 
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Home Agent and subtype value 2 is reserved for use by the Foreign 
Agent. Similar to the procedures specified for Mobile IPv4 [RFC3344] 
number spaces, future allocations from this number space require 
expert review [RFC2434]. 
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